1. Field of the Invention
The present invention relates to a method of and a device for generating an access-control list, and particularly relates to a method of and a device for generating an access-control list based on inputting of access-control rules so that a system can execute the generated access-control list with an aim of insuring security of the operation system.
Recent increases in diversity of services and severity of competition in the information-communication industry have resulted in more emphasis being placed on enhancement of operation systems so as to satisfy customer needs. In order to promptly respond to the customer needs, networking of operation systems should be extended beyond the framework of a simple network and connection of elements thereof so as to encompass services allowing customers and operators to access information stored in any devices of a service providing system. Along such extension of networking, types of works that operators attend to are diversified, resulting in an expansion in scale and complexity of a network-management system (NMS).
As relations between the NMS and operators become complicated, management of the relations become more and more important. One of the important issues is how to insure security. Namely, security needs to be established and maintained by imposing access controls, which regulate which operator can perform what operations with respect to which network resources or NMS. Such access controls are preferably flexible enough to cope with an expansion of the network, an extension and modification of the NMS, reorganization,
2. Description of the Related Art
FIG. 1 is an illustrative drawing showing relations between NMS networks and operator responsibilities.
In NMS networks, sections which attend to network operations are classified into a plurality of different levels. At the top level, a network-management center has operators working as network-management personnel, NMS-management personnel, system-management personnel, etc., who control network operations nationwide. At the second level from the top, a sub-network-management center has operators working as network-management personnel, NMS-management personnel, customer-service personnel, etc., who control network operations on a regional/prefectural basis. At the bottom level, a regional network (switch-board office) has operators working as system-installation/maintenance personal and so on. Such NMS networking as described above makes it possible for the operators to access various NMSs and network resources.
As the NMS networking diversifies operator responsibilities, it becomes increasingly important to manage the relations between the NMS/network resources and the operators. One of the important issues is the management of operator authority.
Operator authority is generally determined based on:
a) position titles (e.g., service-maintenance staff, nationwide-NMS-management staff, and so on); PA1 b) organizational structures (e.g., responsible for network-element maintenance within an assigned area, responsible for NMS management within offices, and so on); PA1 c) property of managed objects (e.g. responsible for management of paths crossing area borders). PA1 A+ John{subscribe}bridge_failure_event PA1 A- Students{reboot}teaching_workstations PA1 A+ x:Managers{read}development_directory PA1 Manager 2 A+ Object 1 PA1 Manager 3 A+ Object 2 PA1 &lt;transmission-line operator, A1, service-management device&gt;. PA1 &lt;transmission-line operator, A1, service-management device&gt; PA1 &lt;switch-board operator, A2, traffic-management device&gt; PA1 &lt;transmission-line operator, A1, service-management device, manager's organization=organization which controls the target&gt; PA1 &lt;transmission-line operator with organization 1, A1, service-management device of organization 1&gt; PA1 &lt;transmission-line operator with organization 2, A1, service-management device of organization 2&gt; PA1 &lt;transmission-line operator, A1, service-management device, C1&gt; PA1 &lt;switch-board operator, A2, traffic-management device, C2&gt; PA1 &lt;transmission-line operator, A1, service-management device, C1&gt;generates a relation: PA1 &lt;transmission-line operator (manager 1, manager 2), PA1 A1, service-management device (target 1, target 2)&gt;, and, then, further generates four access-control lists as follows.
Relations between the authority and the NMS/network resources can be managed by imposing access control which is executable by the operation system. However, operability in maintenance of access-control rules, which forms a basis of the access control, is an issue that needs to be attended to. Also, performance of the access control on a distributed system and an influence on the operator operations are other issues that needs to be attended to.
FIG. 2A is a table chart showing access-control guidelines (security guidelines) which forms a basis of the access-control rules.
A table of FIG. 2A shows relations between job assignment and responsibility (accessible information). In the figure, the symbol "A" indicates an "authorized" status, and the symbol "N" signifies a "non-authorized" status. Further, the symbol "Cn" indicates restrictions attached to the access-control rules. For example, "C1" means that access is authorized only when a managed object is placed within the assigned area. Also, "C2" means that access is authorized only when the managed object is in the assigned area or resides across the boundary between the assigned area and another area.
According to the access-control guidelines shown in FIG. 2A, the system-management staff can access all the managed objects. The assigned-area-NW-management staff cannot attend to the NMS-NW control (network control relating to the NMS), but can attend to the NW control within the assigned area and across borders between the assigned area and another area. Further, the assigned-area-NMS-management staff cannot handle the NW control and the NW monitoring, but can attend to the NMS-NW control within the assigned area and across borders between the assigned area and another area. The customer-service staff can only handle service monitoring which relates to customers.
Such access-control guidelines as described above is manually converted into a description describing the access control rules that are executable by the system, and, then , is input to the system.
In this case, relations between managers and managed objects in a distributed management system needs to be controlled. Management policy is a scheme that achieves this objective (M. Sloman, "policy Driven Management for Distributed Systems", Journal of Network and Systems Management, Vol. 2, pp. 333-360, 1994, a disclosure of which is hereby incorporated by reference).
Management policy includes two types policies. One is authorization policy which relates to authorization of message exchange, and the other is obligation policy which relates to obligation of message exchange. Here, a close look is taken at the authorization policy since it directly relates to the access control.
The authorization policy can describe a group of manager objects (i.e., a manager domain), a group of a managed-target objects (i.e., a target domain), a set of operation messages exchanged between the manager domain and the target domain, constraint conditions imposed upon exchange of messages, etc. The following is a syntax of an authorization policy.
["A+".linevert split."A-"]Manager"{"Action"}"Target when Condition Here, "A+" is an authorization policy, and "A-" is a negative authorization policy. "Manager" and "Target" are domain names. "Action" is a message name, and "Condition" is a description regarding restrictions.
In what follows, examples of descriptions of authorization policies (access-control rules) will be shown.
This authorization policy (A+) describes that John can subscribe a failure event that occurs in a bridge device.
This negative authorization policy (A-) describes that students cannot reboot workstations that are provided for educational purposes.
when x.location=planning_office PA2 1) &lt;manager 2, A1, target 1&gt; PA2 2) &lt;manager 2, A1, target 2&gt; PA2 3) &lt;manager 3, A1, target 1&gt; PA2 4) &lt;manager 3, A1, target 2&gt;
This authorization policy (A+) has a constraint condition attached thereto, and describes that manager x can read a development directory only when manager x is in a planning office.
In this manner, access-control rules based on the management policy permits use of constraint conditions (C:Condition). In general, however, a machine process for recognizing the constraint conditions involves complex tasks, and is a rather difficult process. Because of this, an interpreter which generates an access-control list (ACL) executable by the system does not actually translate the constraint conditions C attached to the access-control rules. The constraint conditions C are merely permitted to accompany the access-control rules.
FIG. 2B is an illustrative drawing showing an example of an organizational structure of an NMS network system.
In FIG. 2B, an access manager 2 belongs a division 1, and is a transmission-line operator. An access target 1 is under the control of the division 1, and is a service-management device. An access manager 3 belongs a division 2, and is a transmission-line operator. An access target 2 is under the control of the division 2, and is a service-management device.
Access-control guidelines for the NMS network system described above may permit the manager 2 of the division 1 to access the target 1 of the division 1, and may permit the manager 3 of the division 2 to access the target 2 of the division 2.
When the access-control guidelines as described above need to be described as authorization policies, access-control rules need to be written down by a pen and paper by examining the organizational chart of FIG. 2B, describing various actions A with respect to each manager (name) and each target (device) as follows.
This is how the management policy of the related art is processed.
In the related art, a concept "role" is utilized when describing the management policy (E. Lupu, D. Marriott, M. Sloman, N. Yialelis, "A Policy Based Role Framework for Access Control", First ACM/NIST Role Based Access Control Workshop, December 1995, a disclosure of which is hereby incorporated by reference).
The concept "role" models responsibilities and duties associated with a position within an organization. Access managers are grouped by roles with an aim of simplifying descriptions of access-control rules. In the following, access control based on this concept "role" will be described.
FIG. 3 is an illustrative drawing showing access control using the role.
A manager 2 sends an action A1 to a target 1. In this case, an access-control operation unit 62 obtains identify information from a role table so as to learn that the manager 2 is a transmission-line operator and the target 1 is a service-management device. Further, the access-control operation unit 62 attends to access control based on whether an access-control-rule table includes an access-control rule:
In this case, a person who makes the rules may describe the following access-control rules, for example.
In this manner, use of roles eliminates a need to describe a large number of access-control rules defining actions with respect to each manager and each target. This reduces the load on the person who describes the rules.
The person who describes rules may, of course, describe constraint conditions. However, there is no technology available yet for interpreting constraint conditions directly from access-control rules. Because of this, even when a constraint condition:
needs to be described, the person who describes rules cannot just write this down and leave it as it is. Rather, the person who describes rules needs to write down and repeat a description of access-control rules as many times as the number of organizations as in the following.
This means that there is a need to describe a large number of access-control rules.
Use of the concept "role" as described above may make it possible to convert an access-control rules as originally input into an access-control list executable by the system. What will be described in the following is not known to others or used by others, and, thus, does not constitute prior art. The following description is provided because of its significance in helping to understand the concept "role".
FIG. 4 is an illustrative drawing for explaining an exemplary method of generating an access-control list using roles.
A system shown in FIG. 4 includes a role table 72 and a target table 73. The role table 72 relates access-manager types (roles) to individual access managers (staff names) who belong to respective roles. The target table 73 relates access-target types to individual access targets which belong to respective types. Access-control rules in this case are described by the management policy &lt;M, A, T, C&gt;
The person who describes rules can create the following access-control rules, for example, by using the organizational structure shown in FIG. 2.
A access-control-list generating unit 71 refers to the role table 72 and the target table 73 based on the input access-control rules, and generates an access-control list comprised of three items &lt;M, A, T&gt;, i.e., an access manager M, an action A, and an access target T.
The access-control list (ACL) is input to the access-control-operation unit of the system, and describes which method/command is permitted with respect to which access manager and which access targets. Such a description is provided in the three-item form &lt;M, A, T&gt;.
Even in this case, constraint conditions C1 and C2 that are attached to the access-control rules are permitted to be part of descriptions, but are not used in generating the access-control list. As a result, the access-control rule of this example:
As can be understood, the lists 1) and 4) are in accordance with the access-control guidelines. The generated results, however, include the lists 2) and 3) which are not in compliance with the access-control guidelines. That is, the list 2) indicates that the manager 2 of the division 1 can access the target 2 of the division 2, which is a false. Also, the list 3) shows that the manager 3 of the division 2 can access the target 1 of the division 1, which is not true.
In this manner, the management-policy scheme and the role scheme of the related art allow constraint conditions to be described as part of the access-control rules. These constraint conditions, however, are not interpreted by the access-control-list generating unit or the access-control operation unit, so that the person who makes the rules needs to write down a large number of descriptions of access-control rules defining actions with respect to individual managers, targets, and/or organizations.
Even if the concept "role" is utilized in an attempt to convert access-control rules into access-control lists, constraint conditions attached to the access-control rules are disregarded when translating the rules into the access-control list. Because of this, the access-control list thus generated may include lists which are not in compliance with the access-control guidelines of the system. Elimination of the non-complying access-control lists requires a significant amount of time and labor.
Further, when a change is made to a configuration of the operation system or security policies, such as when there is an expansion of the network, a change in organizations where access managers belong, a change in authorization, a change in organizations controlling access targets, or the like, it becomes necessary to input another set of access-control rules by taking into account various constraint conditions in existence between the organizations where access managers belong and the organizations which control the access targets. According to the related-art scheme described above, however, the person who makes the rules needs to consider both the access-control rules and the constraint conditions imposed by the organizational structure, so that it is extremely difficult for him/her to identify every change that needs to be made. Further, the amount of data input (i.e., the amount of labor) necessary for describing access-control rules is unduly increased.
Accordingly, there is a need for a method of and a device for generating access-control lists wherein the method and the device allows access-control rules to be easily constructed and modified.